feat(sources): RSS provider 3/4 — freshness engine, partition-per-feed exec, table providers, registration + public egress seam - #182

[P1] Move feed parsing off Tokio worker threads

parse_feed_document synchronously performs sanitation, feed parsing, DOM construction, and HTML-to-Markdown conversion over attacker-authored input of up to the configured response cap. Because it runs inside the async serve future, several pathological feeds can occupy the runtime workers and stall unrelated server work; the surrounding timeout_at cannot interrupt synchronous CPU work once this call starts. Please move this stage to a bounded blocking/CPU executor and preserve explicit complexity/depth limits and cancellation semantics.

[P1] Coalesce refreshes or generation-check cache commits

An expired snapshot is taken before the permit, and concurrent scans can independently fetch the same feed and commit in completion order. A slower response representing an older window can overwrite a newer successful fetch; a 304 can also re-arm and label whatever window is currently stored even though its validators came from the earlier snapshot. The cache can therefore regress or claim that a window was revalidated when that response never validated it. Please add per-feed singleflight, or attach a generation to the snapshot and reject/reconcile stale success, failure, and 304 commits. Add a concurrent 200/200 and 200/304 ordering test.

[P2] Do not serve cached rows after an egress denial

All FetchError variants enter normal stale degradation, so FetchError::Egress serves an existing window as stale-error. The design explicitly requires a policy refusal to produce zero rows, and a dynamic policy or DNS result can deny a destination after this cache was warmed. Please special-case egress denial so the denied subscription contributes no item rows while health records the refusal, and test denial after a successful cached fetch.

[P2] Cap max_concurrent before constructing the semaphore

Config validation rejects only zero, but Tokio documents that Semaphore::new panics when the permit count exceeds Semaphore::MAX_PERMITS. A valid YAML integer above that threshold therefore aborts registration instead of returning a configuration error, contrary to the no-panics production rule. Clamp the effective value to the subscription count and/or MAX_PERMITS, or reject it during validation, and add an extreme-value regression test.

[P3] ScanShared carries LIMIT + deadline state across execute() calls of one plan object

The spent-LIMIT counter and the deadline (stamped Instant::now() at plan construction, exec.rs:207) live in the plan, not the stream. A plan object executed twice without an intervening reset_state() serves zero rows the second time, and a plan executed after scan_timeout has elapsed since planning degrades every partition to zero rows + warn. The reset_state override covers RecursiveQueryExec, and the test at exec.rs:873 pins the behavior as expected — but correctness now depends on every re-executing operator calling reset_state; a plan cached or re-collected outside that path silently shrinks. Deliberate per the docs, so P3 — but worth a doc note on the provider that this leaf is single-execution unless reset.

Cross-referencing a phase-1 review item (PR #180, thread): the scan deadline must wrap this fetch() call.

The fetcher grants each hop a fresh retry budget, so one fetch() is bounded worst-case at ~300s (6 hops × (3 attempts × 10s request_timeout + 2 waits × 10s MAX_RETRY_WAIT)) — 5× the default scan_timeout_seconds: 60. By design the fetcher only bounds each request/hop, never the whole fetch; the total deadline belongs to this layer.

Right now scan_timeout is stored on RssEngine with only a getter — this await is bare, so scan_timeout_seconds is still enforced by nothing. A malicious or misbehaving server can drag a single feed fetch out to ~300s via slow redirects + retries. Please wrap the whole call, e.g. tokio::time::timeout(self.scan_timeout, self.fetcher.fetch(&sub.url, validators.as_ref())) (not a per-request timeout — the whole future), cancelling the entire fetch when the deadline fires.